Of the “12 ‘planned’ and ‘not certified'”, 10 are planned, which means that 21 of the 23 will be certified in the not too distant future (and keep in mind that many of the 10 “planned” haven’t even been released yet). 21 of 23 is over 90%, and as I said before, when you factor in market share, we’re even higher than that. There’s plenty to be critical of as far as the LSB goes (historically speaking—we’ve come a very long way in the past year!), but distro support isn’t one of ’em.

-ian

Re: http://www.freestandards.org/en/LSB_Distribution_Status

I count 12 “planned” and “not certified”, out of the listed 23, which makes up to 50%. The list is incomplete.

(I observe that ubuntu is certified, while debian is not.)

So, what was your point?

You said, “Klik is great but I don’t want these 10 virtual drives in my directory.”

I’m not sure what you meant with “10 virtual drives”. Probably the loopmounted .cmg files? These are not in your home directory, they are currently mounted in /tmp/app or /tmp/mnt

In a not too distant future (when we can rely on FUSE [file systems in user space) to be present on most systems), we will probably use the fuse mounting abilities… (and, there are some more alternatives to explore).

I mean just the GUI and a reference implementation, say for Ubuntu or Debian and SuSe. So packaging systems for Suse and Debian can be used uniformly by users if they want to use the default component. Sure, distributions can ignore that and come up with their own version but then they have to justify these investments in what is already provided.

This also applies for system configuration. There were plans to port YAST to Debian. Tools like qtparted should be integrated into the standard toolchain of KDE. Variation and fragmentation here makes little sense.

LSB sounds promising but does not happen. But there are some things which need to be harmonised. For instance a standard directory for codecs.

install://software-098

—
Klik is great but I don’t want these 10 virtual drives in my directory.

—

Software description: We have a commercial standard format for these: PAD
http://www.asp-shareware.org/pad/index.asp
Open Source does usually not support it.

“However, Klik isn’t decentralised (there can’t be two different klik packages in the world both called ‘convert’ for example, and if the central server is down then nothing can be installed anywhere in the world).”

Thomas, that’s right — klik isn’t decentralized. Yet.

You can probably imagine that the klik client can be easily extended? So it attempts contacting not just one, but (in turn) two, five, hundred,… $any_number of different klik server mirrors for fetching a specific recipe until it succeeds?

What you point out is not a fundamental, eternally binding limitation of klik’s design, but just one in the current implementation of its basic principles (an implementation which is a “usable Alpha”).

If we agreed all for now, that the basic ideas and architecture of klik are great, we can have multiple klik servers implemented next week who would regularly synchronize their recipes and load balance their activities.

However, that agreement is probably not yet here. :-)

(Your other point, about two different packages named “convert” I didn’t quite get. You can’t be meaning that the same package name should be able to map to two different things [where f.e. one of the converts would be a “destroy”]…)

No question, there are opportunities for improvement here, and as I said in the original post, “[f]rom [here], perhaps we can do more, but even the first steps can be quite valuable in their own right”. One issue we briefly talked about at the Packaging Summit was the repo metadata project, which could conceivably make it possible to create a single repository format that APT or yum could consume. Another was better tools—if it were easier to create RPMs, and if it were easy (and possible) to create a single repository for APT and yum, would ISVs do it? The first steps have to be small. Adoption is key, and you don’t get adoption by ripping and replacing, no matter how good your replacement is.. The answer to that last question from the ISVs in the room, by the way, was “no”. There’s simply no interest in supporting Linux specific package systems today. Now, if enough software purchasers and administrators vote with their wallets that ISVs support these package systems, I suspect they’d change their answer pretty quickly. However, the fact of the matter is that it’s not a priority today, and our goal is to improve the situation given the current environment.

P.S. – We’d love to have end user participation—join the mailing list and get involved!

-ian

I’m not sure where you come up with the assertion that “there are many different implementations of linux that ignore the LSB”.. Take a look at http://www.freestandards.org/en/LSB_Distribution_Status, and you’ll see that virtually every distribution you can think of is either LSB certified today or will be LSB certified in its next version. There are a few exceptions (e.g., Gentoo), but I’d hardly call those few “many”, and even with those few exceptions, the current list has to represent 99% or more market share in total. That’s pretty broad support by any measure.

-ian

The LSB requires a certain set of interfaces, which means that application developers can depend on those interfaces being present (and with the expected behavior) on any LSB compliant distribution. When application developers need to go beyond that set of interfaces, they can bundle the interfaces with the application, either by static linking or shipping the dynamic libraries.

-ian